Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve existing --no-checkout flag #926

Merged
merged 2 commits into from
Oct 25, 2023
Merged

Improve existing --no-checkout flag #926

merged 2 commits into from
Oct 25, 2023

Conversation

olsen232
Copy link
Collaborator

@olsen232 olsen232 commented Oct 19, 2023

kart import supports --no-checkout, but it merely postpones creating a working copy. As of this commit, it will add also add the dataset to a set of non-checkout datasets in the config, so the dataset will stay out of the WC indefinitely.

Also adds kart checkout --dataset=foo --not-dataset=bar flags to add and remove datasets from the set of non-checkout datasets

Still TODO: show what the current set of non-checkout datasets is in kart status

Related links:

#905

Checklist:

  • Have you reviewed your own change?
  • Have you included test(s)?
  • Have you updated the changelog?

@olsen232 olsen232 force-pushed the non-checkout-datasets branch from 1872779 to ddd444c Compare October 19, 2023 23:59
@olsen232 olsen232 requested a review from craigds October 20, 2023 00:01
@olsen232 olsen232 force-pushed the non-checkout-datasets branch 2 times, most recently from 587e09c to 11007c6 Compare October 20, 2023 02:40
kart import supports --no-checkout, but it merely postpones
creating a working copy. As of this commit, it will add
also add the dataset to a set of non-checkout datasets in the
config, so the dataset will stay out of the WC indefinitely.

Also adds `kart checkout --dataset=foo --not-dataset=bar` flags
to add and remove datasets from the set of non-checkout datasets
@olsen232 olsen232 force-pushed the non-checkout-datasets branch from 11007c6 to 4b4874f Compare October 20, 2023 03:41
kart/repo.py Outdated
result = set()
config = self.config
for entry in config:
parts = entry.name.split(".")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, paths can contain dots (a.b.c is a valid path) - should this config structure be adjusted?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch - tested config files and pygit2 behaviour, dots are valid in the middle part (which seems to be the "user-defined" part) but not in the first and last part.
Updated code to recognise and allow for entries that look like dataset.SOME.NAME.WITH.DOTS.checkout

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wild. ok

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I didn't get to this earlier. Git config has standard ways of referring to weird section names, this looks like it's using the older deprecated dot notation?

eg:

[includeIf "gitdir:/path/to/foo/.git"]
	path = /path/to/foo.inc

https://git-scm.com/docs/git-config#_syntax

Sections can be further divided into subsections. To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in the example below:

[section "subsection"]

Subsection names are case sensitive and can contain any characters except newline and the null byte. Doublequote " and backslash can be included by escaping them as " and \, respectively. Backslashes preceding other characters are dropped when reading; for example, \t is read as t and \0 is read as 0. Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have [section] if you have [section "subsection"], but you don’t need to.

There is also a deprecated [section.subsection] syntax. With this syntax, the subsection name is converted to lower-case and is also compared case sensitively. These subsection names follow the same restrictions as section names.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Yup this is fine - in fact I'm using the pygit2 API to access the config (although it's not immediately obvious that I'm doing so from this code). pygit2's API converts git's more complicated syntax[section "subsection"] key = value into a mostly-simpler global key that looks like section.subsection.key - and as of Craig's comment, I tested to see if it can handle subsections with dots in, eg [section "subsection.with.dots"] key = value - it can, and for API access it converts it again to section.subsection.with.dots.key which I have handled now, it's straightforward as long as you know that that's what it will do.

@olsen232 olsen232 merged commit 89ea0e2 into master Oct 25, 2023
32 checks passed
@olsen232 olsen232 deleted the non-checkout-datasets branch October 25, 2023 03:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants